home *** CD-ROM | disk | FTP | other *** search
/ Language/OS - Multiplatform Resource Library / LANGUAGE OS.iso / gnu / gpp-1_42.lha / g++-1.42.0 / ideas < prev    next >
Text File  |  1991-10-19  |  7KB  |  149 lines
  1. 1.  use ELIPSES in structure specification, to make sure that underflow is
  2. intentional, or to allow non-0 initialization for fills.
  3.  
  4. 3.  Implement a C -> C compiler which inserts inline GDB statements.
  5. This will hurt optimization, but may allow for much freer debugging.
  6. Also implies determining on what level exactly that GDB statements are
  7. generated.
  8.  
  9. 4.  C virtual machine (infinite regs and cast operators?)
  10.  
  11. 5.  Make multi-type machine insns.  This may match faster than normal
  12. insn recog phase.  (Using bits for disjuntive decisions.)
  13.  
  14. 30.  Look at syntax more closely to fix up all those s/r conflicts.
  15. Make sure that C++ syntax is reasonably well implemented.
  16.  
  17. 52.  How to make GDB understand operator overloading...
  18.  
  19. 59.  Optimized bitfield accesses such as TREE_X (X) && TREE_Y (X) &&
  20. TREE_Z (X) as bit operation.  Some work has been done on this in
  21. cplus-type2.c, but really should be merged with expr.c.
  22.  
  23. 67.  How does one distinguish between a declaration of a function
  24. taking no arguments from a call to a constructor which takes no
  25. arguments?
  26.  
  27. 72.  How do we make operator[](), operator()(), and operator->()
  28. members-only functions?
  29.  
  30. 73.  The strategy for doing overloaded operators is to have pointer
  31. from an aggregate type to an op table.  If this pointer is NULL, then
  32. no operator overloading to check.  Otherwise, the op table is a hash
  33. table, which suitably indexed by the function, will yield the current
  34. list of argument lists that we can accept.  These argument lists are
  35. hashed to save space (and some time).
  36.  
  37. 77.  Look at making typenames stackable by recovering shadowed
  38. declarations from the tags (during poplevel) back to the TREE_TYPE of
  39. the IDENTIFIER_NODES.
  40.  
  41. 83.  In some situations it is possible to optimize virtual functions,
  42. making them either direct calls, or actually calling them inline!
  43. Identifier the cases where this may be done, and implement this
  44. optimization.  Currently, if a variable has decidedly static type
  45. (i.e., it is a VAR_DECL of aggregate type), then calls through the
  46. virtual function table are eliminated.  This could be extended to use
  47. flow analysis to help with pointers.  Doing PARM_DECLs might be very
  48. hard.
  49.  
  50. As a follow-on, accessing base parts of objects which use virtual
  51. baseclasses can be optimized if the type is statically knowable.
  52. This would involve changes to `build_vbase_path'.
  53.  
  54. 88.  Make default parameters for inline functions live on the
  55. permanent obstack in a more natural fashion.
  56.  
  57. 89.  Should default parameter specifications be permitted to refer to
  58. other parameters in the list? I.e., should "f (int a = 0, int b = a + 5)"
  59. be a permissable declaration?
  60.  
  61. 93.  Set a bit on nodes which says whether default-conversion has been
  62. called for that node or not.  This would mean that any type-altering
  63. actions (which are by-and-large rare) would need to be more careful,
  64. but it might help speed up the front-end.
  65.  
  66. 99.  When using reference types, two kinds of temporary variables are
  67. needed.  One whose scope is the scope of a block, one whose scope is
  68. the scope of a stmt.  The latter is needed when a function takes
  69. reference parameters, and those references exist only for the calling
  70. of that function.
  71.  
  72. 105.  Applying the maxim "Same sh*t, different day" to compiler
  73. implementation, we note that when initializing or destroying
  74. aggregates, the tree structure we create for such actions is always
  75. the same for any given type, only the address we are operating on
  76. changes.  Memoize the tree structure for each type, so that init and
  77. delete code can be generated efficiently, without large walks.
  78. In fact, we might even want to memoize the rtl code for this for real
  79. speed.  --No, this tradeoff appears poor in speed/space.
  80.  
  81. 110.  Attach a pseudo-variable to all pointers to aggregate objects
  82. which is a pointer to its virtual function table.  CSE can be told
  83. that it is a pointer to constant storage.  If the base pointer is not
  84. assigned during its lifetime, then virtual function references can be
  85. made more efficiently.  This would be more general than the current
  86. hack (of treating `this' as constant).
  87.  
  88. 111.  Generate efficient (and expected) code for constructs of the
  89. form "X x = X (args)".  Though this should be equivalent to "X x (args)", 
  90. the current implementation make it behave like "X t (args); X x = t;".
  91. This code could cause some programs to fail if they do not have X(X&)
  92. defined.
  93.  
  94. 112.  Look at overloading functions based on their return type.
  95.  
  96. 113.  Arrays which are indexed by a constant, and are known to contain
  97. a constant at that address should be able to produce that constant
  98. during tree-build time.
  99.  
  100. 114.  Split ctors into vbase-initialization and regular initialization
  101. to avoid need for "in-charge" flag.
  102.  
  103. 115.  Register-based objects and `const' constructors.
  104.  
  105. 116.  VAR_DECL and PARM_DECL should have a slot knowing themselves as
  106. INDIRECT_REFs if they are pointers, and ADDR_EXPRs if they are not.
  107.  
  108.     Return-Path: <bothner@cs.wisc.edu>
  109.     To: bug-g++@prep.ai.mit.edu
  110.     Cc: bothner@cs.wisc.edu
  111.     Subject: G++ wishlist
  112.     Date: Mon, 05 Mar 90 13:42:38 CST
  113.     From: bothner@cs.wisc.edu
  114.  
  115.     A couple of items for the "Projects" section of the g++ manual.
  116.     (The first two imply incompatible changes to binaries, so getting
  117.     them into Gcc/g++ version 2.0 would be nice.)
  118.  
  119. 117.* Implement cfront-2.0-style virtual table rules: If a class has
  120.     a non-inline method, emit the virtual table iff the first such
  121.     method has been defined in the current compilation unit. Or some
  122.     such rule to emit only a single copy of each vtable.
  123.  
  124. 118.* Go back to the single-inheritance implementation of virtual
  125.     table fields (i.e. only a single pointer) and virtual method
  126.     calls (i.e. just an indirect jump without adjusting 'this').
  127.     Handle the multiple-inheritance case (i.e. when the 'delta != 0')
  128.     by having the vtable entry point to a stub routine of the form:
  129.  
  130.     stub_foo:
  131.         /* if vax: entry_code inserted by linker */
  132.         this += delta;
  133.         goto real_foo;
  134.  
  135. 119.* Some way of allowing static objects to be initialized at compile-time.
  136.     This would decrease code size and startup-time.
  137.     -Either:
  138.     * Allow C-style initialization lists (even when the class has
  139.     a constructor).
  140.     -Or:
  141.     * Optimize simple constructor calls by doing them at compile-time.
  142.     By "simple" constructors I mean ones that are lists of just
  143.     simple assignments, with constant RHS.
  144.     -or ideally both!
  145.  
  146.         --Per Bothner
  147.     bothner@cs.wisc.edu Computer Science Dept, U. of Wisconsin-Madison
  148.  
  149.